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INFORMATION EXCHANGE ENGINE PROVIDING A CRITICAL 
INFRASTRUCTURE LAYER AND METHODS OF USE THEREOF 

CROSS-REFERENCE TO RELATED APPLICATIONS 
5 This application claims priority from U.S. Provisional Patent Application 

No. 60/172,977 entitled "Web-Based Personal Data Repository and Access 
Management System and Methods of Use Thereof," fited on December 20, 1999. 

BACKGROUND 

10 Field of the invention 

The present invention relates generally to information technology, and 
more particularly to systems and methods for providing dynamic creation, 
storage and exchange of personal information. 
Description of Related Art 

15 With the evolution of social interaction, people feel the need to exchange 

personal and business information with each other. In addition, with the 
advancement and proliferation of communication technology, people have 
acquired more and more personal contact information, such as electronic mail 
addresses, mobile phone numbers, and the like. These issues, coupled with the 

2 0 dynamic nature of society, has created a need for an easier, more accurate way 
to store personal information, to maintain its accuracy and currentness, and to 
exchange it with others. 

With the advancement and proliferation of computer network 
technology, people and businesses have increasingly relied on computers, 

2 5 computer networks, handheld electronic devices, and the like to manage their 

vast amount of personal and business information. Thus, there is a further need 
for convergence of a robust data management system with network 
communication technologies to fill the need for a flexible, easily updateable, 
real-time information exchange mechanism. 



1 
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SUMMARY 

An information exchange system which provides a critical infrastructure 
layer, and methods of user thereof, are described. The information exchange 
system provides a tool for dynamically defining data records and "dynamically 
5 allocating instances of those records. The system further provides a tool for 

facilitating electronic exchange of personal information represented by the data, 
such as contact, payment, shipping, and other information, between individuals 
and the people and businesses with which they interact. The system allows 
editing and sharing of information at a data field level, in addition to supporting 

10 information transactions at a complex level, defined as a combination of related 
fields. The architecture of one embodiment is such that the system can be 
coupled with a conventional relational database application. 

The information exchange system comprises an interface layer providing 
a tool for users to interact with the system through a plurality of client-side 

15 platforms. The system also comprises an application layer comprising a vault 
providing a storage mechanism for individual and business users to store 
information about themselves and /or their business, and a contact manager 
providing a utility for saving information about static and dynamic contacts. 

The system further comprises a critical exchange engine layer comprising 

2 0 an account manager, a virtual record manager, a data exchange engine, and an 
encryption engine which provides the capability to save and access raw data 
that has been encrypted in a relational database. The virtual record manager is 
configured to manage the storage of data, whereby support for complex data 
records is supported while maintaining access and control of data on an 

2 5 individual field basis. The data exchange engine supports the exchange of 

information between system users and the definition and enforcement of rule- 
based behaviors on the availability of information. 

A database is provided in one embodiment for storage of encrypted 
personal information of system users, for storage of metadata describing the 

3 0 structure and description of the personal information stored in the database, and 
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for storage of permissions data describing sharing and accessibility rules related 
to the fields of information. 

The system generally provides a private, accurate, convenient, and secure 
method of maintaining and accessing up-to-date information at any time from 
5 anywhere. Users are able to expand and customize their information readily 
and in real-time. The information in the robust data repository can be accessed 
through a WAN such as the Internet or through various- handheld wireless 
devices. Upon a change of information, all persons that have permission to 
view that information field are alerted and updated automatically with the new 
10 data. 

Although uses of the information exchange system described herein are 
many, several are provided for exemplary purposes. Exemplary uses for an 
individual user which are provided by the system include: (1) requesting a 
summary of information that has changed for people, groups, or businesses in 

15 their network of contacts, possibly through a personal newsletter or as 

highlighted boxes on a system home page, thus being automatically informed of 
changes; (2) maintaining a community address book whereby clubs, 
organizations, chat groups, etc. can maintain current information on members 
which can be reflected in distribution lists or instant messaging buddy lists 

2 0 linked to the system; (3) drawing on information already stored in the system to 
save time filling out on-line registration, commerce, and site log-in forms 
preferably by supplying a system ID to the site of interest which is linked to 
personal, commerce, and site specific user name/ password information of the 
user; and (4) automatically notify friends, relatives, and businesses when a user 

2 5 moves, providing the new personal information immediately. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
In the accompanying drawing: 

FIG. 1 depicts a preferred operating architecture of an information exchange 
system, according to an embodiment of the invention. 



4 
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DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
FIG. 1 depicts a preferred operating architecture 100 of the information 
exchange system 102 described herein. The overall system architecture 100 is 
based on a network client-server model, wherein various client 110 platforms 
5 communicate with a layer of applications 140 through a network 120. Since the 
information exchange system 102 supports a plurality of client platforms (which 
are discussed in detail below), an interface layer 130 comprising interface 
servers is provided for interacting with the plurality of client-side platforms. 
The information that is exchanged by users of the system 102 is maintained in a 
10 database 160. The critical infrastructure layer that primarily provides the 

operational capability of the system 102 to facilitate the storage, modification, 
and exchange of information for people and businesses lies in the exchange 
engine layer 150. 

The application layer 140 and its components are described prior to the 
15 detailed description of the interface layer 130, so it is noted that a client user 

interacts with the system 102 and its application layer 140 through the interface 
layer 130. The application layer 140 contains a vault 142 and a contact manager 
148. The vault is depicted as containing constituent elements for individual 144 
and business 146 applications for didactic purposes, but configurations are 

2 0 contemplated wherein the needs of both individual and business users are 

provided by a single vault 142 application. 

The vault 142 is an application that provides a storage mechanism for 
registered individual and business users of the system 102 to store information 
about themselves and /or their business. Non-limiting examples of an 
25 individual user's information include name, home and office addresses, home, 
office, mobile phone and various other phone numbers, date of birth, as well as 
similar information about the user's spouse and children. Additional examples 
include names and membership numbers related to various organizations of 
which the user is a member, bank and mortgage information, and similar 

3 0 information. A user's information may be described within the system 102 in 

5 
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relation to various permission groups to facilitate management by the user, e.g., 
groups such as "family," "work," "financial," "social," "recreational," etc. Non- 
limiting examples of a business user's information include the business name, 
address of their headquarters and branch offices, names of the c6mpany 
executives, Dun and Bradstreet number, tax identification number, bank account 
information, membership in various organizations, etc. 

The vault 142 presents the registered user with-^number of fields with 
predefined semantics. To this end, the vault 142 utilizes information stored and 
managed by the account manager engine 152, to know if the user is a business 
user or an individual user. For example, the vault 142 may present "name" and 
"home address" fields to an individual user, whereas it may present "office 
phone number" and "D&B number" fields to a business user. The number of 
fields of information and the nature of the fields are decided by each registered 
user of the system, and are not limited to those presented. Consequently, the 
exchange system 102 is configured to facilitate the exchange of dynamic, user- 
defined information and types of information. 

The vault 142 invokes the virtual record manager (VRM) 154 of exchange 
engine layer 150 to actually store and retrieve the information. In managing the 
information, the vault 142 queries the VRM 154 using an internal account ID of 
the registered user as a parameter of the query. The VRM 154 provides the 
name, value, and an internal ID of every field in which the user has stored 
information. The vault 142 also provides to the user the information stored in 
each of these fields. Upon user modification of any of the user's information 
fields, the vault 142 provides to the VRM 154 the fields that have changed and 
the VRM 154 subsequently stores the modifications in the database 160. Upon 
user creation of a new field of a particular type, the vault 142 directs the VRM 
154 to allocate memory for the new field. The VRM 154 operates to allocate 
sufficient memory to store the new field and the related information depending 
on the type of the field created, such as text or numeral/simple or complex, and 



30 the like. 
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The contact manager 148 is an application similar to a conventional 
address book application, but providing a number of novel features. The 
contact manager 148 provides to users a utility for saving information about 
their contacts, i.e., people with whom the users desire to keep communicative 
5 contact. The contact manager 148 differentiates between two types of contacts, 
static and dynamic contacts. 

Static contacts are defined as those in which information is provided to 
the system 102 by a user. For example, an individual user could employ the 
system to store the name of a friend and an associated home and work phone 

10 numbers and home address, whereby this information is not provided to the 
system directly by friend. If the friend were to change residence (and hence 
home address and home phone number), the user would need to re-enter these 
changes into the system 102. 

In contrast, dynamic contacts are those in which information is provided 

15 to the system 102 directly by the contact person and is shared with others 

through operation of embodiments of the system 102. For example, if a user 
desires to have a friend's information in a personal list of contacts managed in 
the system 102 and if the friend is a registered user of the system 102, the user 
does not need to provide the friend's information to the system. The friend 

2 0 would directly save personal information in the system 102, utilizing the vault 
142 application as previously described. The friend would then permit the 
system 102 to share portions of personal information, e.g., home and office 
phone numbers, with the user. The user would consequently find the personal 
list of contacts to include the friend with the relevant information that the user 

2 5 has is permitted to access and view. If the friend were to modify any portion of 

the information that is being shared with the user, the user wall be able to view 
the new information when viewing the personal contact list. In addition, the 
system 102, primarily through operation of a data exchange engine 156 of 
exchange engine layer 150 and permissions data 166 of database 160, provides 

3 0 the capability for the friend to manage access to personal information by 

7 
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directing the contact manager 148 to share this or any other personal 
information with the user for a defined period of time only. After expiration of 
this defined period, the user will no longer be able to view the friend's 
information. 

5 The contact manager 148 manages the information about each registered 

user's static contacts by storing these in the database 160 and retrieving it when 
necessary. In contrast, to manage dynamic contacts thHtrontact manager 148 
invokes the VRM 154 and the data exchange engine (DXE) 156. The contact 
manager 148 first invokes the account manager 152 to verify that the user 

1 0 logging in to the system 102 is a registered user and to retrieve the internal 

account ID of the user. The contact manager 148 would then communicate with 
the VRM 154, providing the VRM 154 with the account ID of the registered user. 
The VRM 154 is operative to retrieve from the database 160 and to present to the 
user the names and account IDs of the user's dynamic contacts. The contact 

1 5 manager 148 then invokes the DXE 156 to determine which fields of each 
dynamic contact are being shared with this registered user. 

Once the contact manager 148 is familiar with the fields (represented as 
field IDs) shared by one registered user with another (i.e., shared by the 
dynamic contact with the logged-in user), it invokes the VRM 154 to read the 

2 0 contents of the shared fields. The system 102 is capable of then providing the 

content of these fields to the appropriate interface layer server 131-139, for 
transmission to the associated client platform 111-119. 

It is noteworthy that the contact manager 148 provides a rich set of 
information about a user's contacts, including every piece of information that 
25 the contact registered user allows one to see. In addition, the contact manager 
148 provides the capability for the user to query the contact manager 148 in 
order to determine who has actually viewed which personal information fields 
in their information repository. Furthermore, if a personal information field has 
been constructed as time-limited, the system 102 will automatically stop sharing 

3 0 this information upon expiration of the associated time limit. 

8 
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Reference is directed to the exchange engine layer 150, which comprises 
the account manager 152, the virtual record manager (VRM) 154, the data 
exchange engine (DXE) 156, and the encryption engine 158. The account 
manager 152 manages account information about each registered user. This 
5 information includes, but is not limited to, whether a user is a business or 
individual user, their internal account ID and password, the last time they 
logged into the system 102, whether their registration^ still active, etc. The 
account manager 152 also implements security rules that inactivate a registered 
user's account upon certain occurrences or non-occurrences. For example, 

10 registered users are considered inactive and thus their accounts inactivated if 

they do not login to the system 102 at least once every six months. Additionally, 
users may be locked out of the system 102 for a 24-hour period if they 
unsuccessfully attempt to login four times during any four-month window. 
The account manager 152 preferably stores the relevant account 

15 information in a table of a relational database. Each row of the table is 

configured to store information about one registered user. The columns of the 
table are preferably configured to represent the registered user's password, the 
last time they logged in to the system 102, whether the user is locked out for a 
security reason, whether the user has changed the login name and the previous 

2 0 login name, and the like. Those skilled in the art may recognize that the 

information stored and managed by the account manager may include more 
than those items listed above and still be within the scope of the present 
invention. 

The virtual record manager (VRM) 154 is configured to manage the 

2 5 storage of data preferably utilizing a conventional relational database. The 

VRM 154 supports complex data type (record) modeling while maintaining 
access and control of data on an individual field basis. For example, the VRM 
154 architecture supports operations on a single-field record, an entire complex 
(multi-field) record, or an individual field within a complex record. 

3 0 Furthermore, the VRM 154 is configured to provide a fully dynamic extensible 

9 
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data store mechanism whereby new instances of data records as well as entirely 
new and possibly unique data types may be defined "on the fly," or 
substantially instantaneous, for each user, without the need for any system 
downtime to perform such operations. 
5 The VRM, 154 operates at the level of a single field of information. For 

instance, each field of information is assigned a unique ID so that operations can 
be performed on individual fields. The fields are also defined for a particular 
user of the system, although sharing of fields between users is possible by 
employing the DXE 156. The information fields are also typed, allowing type- 

10 specific behavior (input data validation, for example) to be implemented. 

To support record-level data modeling, the VRM utilizes the concept of a 
virtual object (VOB) (not shown). The VOB defines a record structure (logical 
collection of individual data fields), and also supports the ability to arbitrarily 
nest record structures. Any number of VOB types can be defined, either 

15 globally accessible by all users or per user of the system, and each VOB type is 
assigned a unique VOB type ID. VOB type information provides the metadata, 
which is generally a definition or description of the data, for the VRM 156 to 
dynamically support arbitrary data types and is stored in the VOB and VOB 
Field of the following database 160 table. 



Database Table 


Description 


VOB 


Metadata for Virtual Objects (VOBs) describing 
elements such as the VOB type name, VOB Type ID, 
etc. There is one row for each VOB type defined. 


VOB.Field 


Metadata describing the individual fields defined for 
each VOB. There is one row for each field within a 
virtual object. 



TABLE 1 



When a new VOB is defined by a user, the VRM 154 searches for the metadata 
for the requested VOB type (via it's unique VOB type ID) and creates a record to 

10 
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reflect the VOB instance (in the VOB_Data table), in addition to all of the 
individual fields defined for the VOB (in the VOB_Field_Data table). This data 
structure is depicted in the following database 160 table. 



Database Table 


Description 


VOBJData 


Instances of VOB types. There is one record for every 
VOB that is instantiated. Each VOB is instantiated for 
a particular user account. 


VOB_Field_Data 


Data for each VOB instance. There is a row for each 
field defined for an instantiated VOB type. 



TABLE 2 



5 

The VRM 154 also supports the ability to control the VOB types available to a 
particular user based on their user class. For example, the VOB types available 
to business users can be defined to be different than those available for 
individual users. 

10 In addition to VOBs, the VRM 154 also supports two additional concepts, 

InfoCards and VRecords. InfoCards provide a convenient way for users to 
share their information using the DXE 156. An InfoCard allows a user to define 
a specific collection of information fields. It is noted that InfoCards differ from 
VOBs in that they can only be defined from a set of already defined fields, and 

15 that the fields selected can actually span across VOBs. To ensure a minimum set 
of data may be exchanged between any two user accounts, the VRM 154 may 
pre-populate every user account with a minimum set of VOBs, and define a set 
of system-defined InfoCards that use those VOBs. The operability of the 
InfoCard feature is provided primarily by the database 160 table depicted. 



Database Table 


Description 


Field_Group 


Contains InfoCards. There is a row for each InfoCard 
defined for a user account. 


Field_G roup_Da ta 


Defines the fields that belong to each InfoCard 
defined. There is a row for each field that is defined 
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Database Table 


Description 




within an InfoCard. 



TABLE 3 



VRecords provide a generic mechanism for the electronic exchange of 
information with third-party systems, a valuable feature for business-to- 
5 business (B2B) electronic commerce. In many cases, aTftird party has a data 
record format that they wish to have returned from the system 102 when 
requesting information about a particular registered user of the system 102. The 
VRecord defines a mapping between the third party record format, and the 
native system 102 record structure as primarily defined by the metadata 164 of 

10 database 160. Employment of a VRecords further allows a user to define a 

mapping based on the user class (e.g. a different mapping can be defined for 
business and individual users). This VRecords feature operates by correlating a 
field ID for each class of user with an output field name selected by the VRecord 
author. The operability of the VRecords feature is provided primarily by the 

15 database 160 table depicted. 



Database Table 


Description 


VRecord 


Contains VRecords. 


VRecord_Dynamic_Data 


Defines field mapping for obtaining information 
from system 102 member accounts. 


VRecor d_S ta t ic_Da ta 


Defines field mapping for obtaining information for 
static contacts defined in the system 102 contact 
manager 148 for the requesting party. Primarily 
useful for synchronization applications. 



TABLE 4 



Some of the operational capability of the VRM 154 is exemplified below 
by describing the effect that occurs in certain tables of database 160 when a 
2 0 transaction is implemented. 

12 
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Define New Record Type 
This example demonstrates the database 160 changes that occur when a 
new VOB type is defined in the system 102. Assume that a user desires to define 
a new record named "Friend" that has the following fields: 
5 -First Name 

- Last Name 

- PhoneNumber — - 

Assuming this is done for user account 250, and that the last VOB_Type_ID used 
was 200, this operation creates the following row in the VOB table: 



Account_ID 


VOB_Type_I 
D 


VOB_Name 


VOB_Description 


250 


205 


Friend 


Record for adding a friend. 



10 TABLE 5 



It also creates the following rows in the VOB_Field table: 



Account_ID 


VOB_Type_ID 


Field_Order 


Field_Label 


Field_Type_ 
ID 


250 


205 


5 


First Name 


1 | 


250 


205 


10 


Last Name 


1 


250 


205 


15 


PhoneNumber 


1 



TABLE 6 



15 Note that in this example, the Field_Type_ID of 1 indicates that these are text 
fields. 

Add New Data Record 
This example demonstrates the database 160 changes that occur when a 
user adds a new data record to the system 102. Assume that a user wishes to 
2 0 add a new data record to their account of type "Friend" as was defined in the 
previous example, with the following values: 
- First Name: Tom 

13 
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- Last Name: Smith 

- Phone Number: 555-1212 

Assuming that the user's account JD is 250, the last VOB_ID used for the account 
was 500, the last Field_ID used for the account was 1250 and the user wishes to 
5 name this record "Tom Smith", this operation creates the following row in the 
VOB_Data table: 



Account_ID 


VOB_ID 


VOB_Type_ID 


VOB_LaBel 


250 


505 


205 


Tom Smith 



TABLE 7 



It also creates the following rows in the VOB_Field_Data table: 



Account_ID 


Field_ID 


VOB_ID 


Field_Order 


Field_Value 


250 


1255 


505 


5 


Tom 


250 


1260 


505 


10 


Smith 


250 


1265 


505 


15 


555-1212 



10 TABLES 

In at least one embodiment, the primary database 160 tables with which 
the VRM 154 interacts to provide the capabilities described above are presented. 
Presentation of these exemplary tables is not intended to limit practice of the 
15 invention to use of only these tables or the specific data table structure 

presented, for those skilled in the art will recognize that a different data and 
table architecture may be implemented and still fall within the scope of the 
invention. 

2 0 The VOB table structure for an exemplary embodiment is as follows: 



VOB Table Column 


Type 


Primary Key 


Description 


Account_ID 


Number 


Yes 


Unique ID that 
identifies the user 
account for which the 
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VOB Table Column 


Type 


Primary Key 


Description 








VOB type is defined. 


VOB_Type_ID 


Number 


Yes 


Unique ID in the scope 
of Account_ID for this 
VOB Type. 


VOB_Name 


Text 


No 


Name of the VOB. type. 


VOB_Description 


Text 


No ~~ 


A description of the 
VOB type. 


YK/1T Taa Mi mo 
AJV1L X cig lNJclITlfc: 


1 exi 


NO 


A name to use for this 
type when translating to 
an XML representation. 



TABLE 9 



The VOB_Field table structure for an exemplary embodiment is as follows: 



VOB_Field Column 


Type 


Primary Key 


Description 


Account_ID 


Number 


Yes 


Unique ID that 
identifies the user 
account for which the 
VOB type is defined. 


VOB_Type_ID 


Number 


Yes 


ID of the VOB Type of 
which this field is a 
member. 


FieldJDrder 


Number 


Yes 


Specifies the relative 
order of this field 
within the VOB Type. 


Field_Label 


Text 


No 


Name of this field. 


FieId_Type_ID 


Number 


No 


ID representing the 
Type of field (text, date, 
CC Type, Country, 
etc.). 
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VOB_Field Column 


Type 


Primary Key 


Description 


Field_Default_Value 


Text 


No 


Default value for the 
field. 


XML_Tag_Name 


Text 


No 


A name to use for this 
field when translating 
to an XML 
"representation 



TABLE 10 



The VOB Data table structure for an exemplary embodiment is as follows: 



VOB_Data Table 
Column 


Type 


Primary key 


Description 


Account_ID 


Number 


Yes 


Unique ID that 
identifies the user 
account for which the 
VOB instance is defined. 


VOBJD 


Number 


Yes 


Unique ID in the scope 
of Account_ID for this 
VOB instance. 


VOB_Type_ID 


Number 


No 


ID of the VOB Type of 
this VOB instance. 


VOB_Label 


Text 


No 


Label to use for this 
VOB instance (for User 
Interface display 
purposes). 


Category_ID 


Number 


No 


Category under which 
this VOB is organized. 


VOBjDrder 


Number 


No 


Order of this VOB 
within the specified 
category. 
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VOB_Data Table 
Column 


Type 


Primary key 


Description 


Show_VOB 


Number 


No 


Allows the fields within 
this VOB to be 
displayed or not. 
0=VOB fields are 
hidden, l=VOB fields 
are shown. 


Public_VOB_ID 


Text 


No 


VOB ID that is used by 
the B2B interface 119. 



TABLE 11 



The VOB_Field_Data table structure for an exemplary embodiment is as follows: 



VOBJField_Data 
Column 


Type 


Primary key 


Description 


Account_ID 


Number 


Yes 


Unique ID that identifies 
the user account for 
which the VOB instance 
is defined. 


Field JD 


Number 


Yes 


Unique ID of this field 
record in the scope of 
Account_ID. 


VOB_ID 


Number 


No 


ID of the VOB that is the 
owner of this field. See 
VOB_Data::VOB_ID. 


Field_Order 


Number 


No 


Order of this field within 
the parent VOB. See 
VOB_Field::Field_Order. 


Field_Value 


Text 


No 


Value of the field. 


Field_Mod 


Date /Tim 


No 


Last time the field value 
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VOt>_rieiu_Lyata 
Column 


Type 


Primary key 


Description 




e 




was modified. 


rLncrypnon 


Number 


\ i 

No 


Indicates the type of 
encryption applied to the 
field. 


Public_Field_ID 


Text 


No 


-Field ID that may be 

notri^i via lilt: DZD 

interface 119 to reference 
this field. 



TABLE 12 



The Field_Group table structure for an exemplary embodiment utilizing the 
InfoCard feature is as follows: 

5 



Field_Group Column 


Type 


Primary key 


Description 


Account_ID 


Number 


Yes 


Unique ID that identifies 
the user account for which 
the InfoCard is defined. 


Group_JD 


Number 


Yes 


Unique ID of this InfoCard 
in the scope of AccountJD. 


Group_Name 


Text 


No 


Name of this InfoCard. 


Required 


Number 


No 


1 = this InfoCard is defined 
by the system and cannot 
be removed. 


Read_Only 


Number 


No 


1 = you cannot edit the 
InfoCard. 

0 = you can edit the 
InfoCard. 


Hidden 


Number 


No 


1 = this group cannot be 
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Field_Group Column 


Type 


Primary key 


Description 








edited or seen. 



TABLE 13 



The Field_Group_Data table structure for an exemplary embodiment utilizing 
the InfoCard feature is as follows: 



Field_Group_Data 
Column 


Type 


Primary key 


Description 


Account_ID 


Number 


Yes 


Unique ID that 
identifies the user 
account for which the 
InfoCard is defined. 


Group_ID 


Number 


Yes 


ID of the InfoCard to 
which this field 
belongs. 


Field_ID 


Number 


Yes 


Field_ID of the field to 
include in the InfoCard. 



5 TABLE 14 



The VRecord table structure for an exemplary embodiment is as follows: 



VRecord Column 


Type 


Primary 
key 


Description 


Account_ID 


Number 


Yes 


Unique ID that identifies the 
user account for which the 
VRecord is defined. 


VRecordJD 


Number 


Yes 


Unique ID in the scope of 
Account_JD for this VRecord. 


VRecord_Name 


Text 


No 


Name of the Vrecord. 


Label 


Text 


No 


Printable name for the VRecord. 



TABLE 15 
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The VRecord_Dynamic_Data table structure for an exemplary embodiment is as 
follows: 



VRecord_Dynamic_Data 
Column 


Type 


Primary 
key 


Description 


Account_ID 


Number 


Yes 


Unique ID that identifies the 
use"Tc*ccount for which the 
VRecord is defined. 


VRecord_ID 


Number 


Yes 


ID of the VRecord to which 
this field belongs. See 
VRecord : : VRecordJD. 


Account_Type_ID 


Number 


Yes 


Indicates the user class that 
this mapping record applies 
to (e.g. business or 
individual account). 


FieldjDrder 


Number 


Yes 


Order within the VRecord 
that this field should be 
maDDpd 

A JL I LI IS IS \_ V-A * 


FieldJD 


Number 


No 


Field_ID of the field to 
include in the Vrecord. 


Label 


Text 


No 


Printable name of the field 
within the Vrecord. 




TABLE 16 




The VRecordJ3tatic_Data table structure for an exemplary embodiment is as 
follows: 


VRecord_S tatic_Da ta 
Column 


Type 


Primary 
key 


Description 


AccountJD 


Number 


Yes 


Unique ID that identifies the 
user account for which the 



20 



BNSDOCID <WO 0148825A1.I. > 



WO 01/46825 



PCT/US00/34660 



VRecord_Static_Data 
Column 


Type 


Primary 
key 


Description 








VRecord is defined. 


VRecord_ID 


Number 


Yes 


ID of the VRecord that this 
field belongs to. See 
VRecord:: VRecord_ID. 


Column_Name 


Text 


Yes 


Name of the column in 
Contact table to use for the 
field. 




in umuer 


1 NO 


Order of the column within 
the Vrecord. 


Label 


Text 


No 


Printable name for the field. 



TABLE 17 



The data exchange engine (DXE) 156 supports the exchange of 
information between users of the system 102. The DXE 156 provides interfaces 
5 to enable users to request information from each other, approve or deny 

requests for information, and provide authorized information. The DXE 156 
also supports the definition and enforcement of rule-based behaviors on the 
availability of information, sharing of information in a global space (public 
directory), sharing of simple text messages, and event triggers based on requests 

10 and changes to authorized information. 

In requesting information from another system 102 user, registered users 
may request either globally defined InfoCards (see the description of InfoCards 
above) of information, or globally defined fields of information from the other 
user. The DXE 156 provides event notification hooks for requests for 

15 information and messages: Users may approve or deny the request by InfoCard 
or field, and apply rules regarding access to any provided information, e.g., 
specifying an expiration date for access to the information. Furthermore, users 
may also provide any field or InfoCard to another user at any time. 
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The DXE 156 further provides interfaces for registered users to view 
information made available to them from other registered users. It is noted that 
when a user changes a field that has been shared, the changed information is 
available to other users immediately. This functionality is operative due to the 
5 DXE 156 architecture, which provides event notification hooks for changes to 
information that is available to other users. 

The DXE 156 is operative to track relationships tretween users in a 
Data_Sharing table. Each record represents what is shared from user A to user 
B. A record exists only if user A is sharing one or fields with user B. In 
10 addition, if user B shares information with user A, an additional record appears 
in the Data_Sharing table. It is in this table that any rules regarding the sharing 
of information between the two users is defined. 

As previously described, users can share information either by specifying 
individual fields of information, or by using the InfoCards feature. This sharing 
15 information is tracked by the DXE 156 in the Data_Sharing_Field_ID and 

Data_Sharing_Group_ID tables (shown below), respectively. The DXE 156 
architecture explicitly normalizes this data in the database 160 to enable the 
capability to perform reverse lookups of shared information, e.g., finding all 
users that you are sharing your home phone number with. It is noted that there 

2 0 is one InfoCard that the DXE 156 treats specially, the Directory InfoCard. The 

Directory InfoCard is given the same ID for all users (which uniquely identifies 
it as the Directory InfoCard) and has the behavior attribute that all fields defined 
within this Infocard are implicitly shared with all other users. For example, 
when an application in the application layer 140 requests the information being 
25 shared by user A with user B, the system 102 returns all of the fields explicitly 
shared by A with B, and all the fields that A has placed in his/her Directory 
InfoCard. 

In at least one embodiment, the primary database 160 tables with which 
the DXE 156 interacts to provide the capabilities described above are presented. 

3 0 Presentation of these exemplary tables is not intended to limit practice of the 
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invention to utilization of only these tables or the specific data table structure 
presented, for those skilled in the art will recognize that a different data and 
table architecture may be implemented and still fall within the scope of the 
invention. 



5 The Data_Sharing table structure for an exemplary embodiment is as follows: 



Column 


Type 


Primary Key 


Description 


AccountJD 


XT 1 

Number 


Yes — - 


Unique identifier for the 
user account that is 
sharing information- 


Recipient_Account_ID 


Number 


Yes 


Unique identifier for the 
user that is receiving the 
information. 


Sharing_Record_ID 0 


Number 


Yes 


Unique identifier for 
this record. 


Expiration_Da te 


Date/Time 


No 


Access to information 
expires on this date. 


Date_Granted 


Date/Time 


No 


Access to information 
was originally granted 
on this date. 


Date_Modified 


Date/Time 


No 


Access to information 
was last modified on 
this date. 


TA 


3LE 18 



The Data_Sharing_Field_ID table structure for an exemplary embodiment is as 
follows: 



Column 


Type 


Primary Key 


Description 


Account_ID 


Number 


Yes 


Unique identifier for the 
user account that is sharing 
information. 
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Recipient_Account_ID 


Number 


Yes 


Unique identifier for the 
user that is receiving the 
information. 


FieldJD 


Number 


i es 


ID of the field that is being 








shared. See 








VOB_Field_Data::Field_ID. 




fABLE 19 





The Data J3haring_Group_JD table structure for an exemplary embodiment is as 
follows: 



Column 


Type 


Primary Key 


Description 


Account_ID 


Number 


Yes 


Unique identifier for the 
user account that is 
sharing information. 


Recipient_Account_ID 


Number 


Yes 


Unique identifier for the 
user that is receiving the 
information. 


Group_ID 


Number 


Yes 


ID of the InfoCard that is 
being shared. See 
Field_Group::Group_ID. 



5 TABLE 20 



The encryption engine 158 provides to the VRM 154 and the DXE 156 the 
capability to save and access raw data that has been encrypted in the relational 
database 160. This feature is critical to ensuring the security of data that is saved 
10 by the system 102, for unencrypted data in a database is very vulnerable to 
attack, even within what is considered a secure network. 

All data read and write requests to the database 160 are implemented 
through the encryption engine 158, making the task of encrypting and 
decrypting transparent to all other layers of the system 102 architecture. The 
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encryption engine 158 supports a plurality of conventional encryption schemes 
on a per field basis. For example, one field in a record may be encrypted using 
128-bit symmetric encryption, while another field in the same record may be 
saved with no encryption at all. The encryption engine 158 architecture also 
5 allows encryption keys to be stored physically separate from the database 160 
server hosting the encrypted data. Employment of this feature makes it even 
more difficult to covertly obtain raw information frorrrthe database 160. 

The database 160 comprises data 162 (user personal information) 
encrypted by the encryption engine 158, metadata 164 as described above 

10 primarily in reference to the VRM 154, and permissions information 166 as 

described above primarily in reference to the DXE 156. As described above, the 
VRM 154 and the DXE 156 interact with the database 160 any time a user's 
personal information is created, edited, or accessed. 

Attention is directed to the interface layer 130, preferably comprising the 

15 WAP (wireless application protocol) interface server 131, the web clipping 

interface server 133, the sync interface server 135, the web interface server 137, 
and the B2B interface server 139. The interface layer 130 is configured to 
manage the user interaction with the system 102. The different interface servers 
131-139 communicate with various client side devices or software across a 

2 0 network 120, preferably a WAN such as the Internet, and manage the user 
interaction with the system 102 utilizing the communication protocol that is 
appropriate for the client side device or client side software. The interface 
servers 131-139 invoke various internal components of the system 102, namely 
the account manager 152, the vault 142 and the DXE 156, to retrieve, edit, and, 

2 5 store information. 

The WAP interface server 131 is focused on interfacing with WAP devices 
111 utilizing the wireless application protocol, such as Internet-enabled mobile 
phones or similar wireless communication devices. The web clipping interface 
server 133 is focused on interfacing with wireless handheld electronic devices 

3 0 113, such as personal digital assistants (PDAs), communicating over a wireless 
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medium utilizing the web clipping protocol. The web interface server 137 is 
focused on interfacing with users accessing the system 102 via a conventional 
web browser 117. The web interface server 137 preferably utilizes the secure 
hypertext transfer protocol (https). 
5 The contact manager 148 manages the list of contacts of a user as 

described above. The sync interface server 135 provides the interface for 
synchronizing the contact information stored in the system 102 with other 
conventional client address books resident on various user handheld or desktop 
devices. The sync interface server 135 is configured to communicate with client 

10 synchronization software 115 residing on the various user handheld or desktop 
devices, via the network 102. 

Finally, the B2B interface server 139 provides an application 
programming interface (API) for registered users to login to the system 102 and 
to query for their information or for information about their contacts. 

15 Additional exemplary operations include changing (add / delete / edit) their 

personal information, sharing their personal information with others, requesting 
others to share their information, and all the other functionality offered by the 
vault 142 and the contact manager 148 applications. The B2B interface server 
139 communicates with client users utilizing https. Upon a client transmission 

2 0 of a request to do a certain action (e.g., manipulate information data 162 or 
permissions data 166), the request is made to the system 102 using the POST 
command of http and, possibly, described using XML (extended Markup 
Language). The B2B interface server 139 processes the request and invokes the 
account manager 152, the vault 142, and the contact manager 148 to perform 

2 5 appropriate subtasks within the request. These three subsystems return 

information or completion status to the B2B interface server 139, which then 
appropriately replies to the client request using the language of XML. Through 
this XML request-reply mechanism, the user can exercise all the functionality of 
the system 102 described above. 
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The B2B interface client 119 depicts any software that can communicate 
over the https protocol and send requests and receive replies from the B2B 
interface server 139. The B2B interface client 119 application is intended to be 
written by users of the system 102, with the goal of integrating the information 
5 exchange service provided by the system 102 with other user databases 
containing personal or business information. For example, if a user of the 
system 102 maintains a list of customers and their contaet information in an 
enterprise database, this user can write a B2B interface client 119 application to 
interface with the B2B interface server 139, and thus the system 102. Through 

10 communication between the proprietary B2B interface client 119 and the B2B 

interface server 139, the user can access contact information about his customers 
from the system 102 and store this contact information in the local enterprise 
database. This feature enables the user's customer information stored on the 
enterprise database to maintain synchronization with the information in the 

15 system 102. 

In addition to the API provided for businesses to link to the system 102, a 
business model is contemplated that would utilize the system 102 to provide a 
myriad of information services to businesses for a fee. The services provided by 
the system 102 assist the business in minimizing their database maintenance 
2 0 costs, reducing customer service/call center costs, and improving sales and 

marketing activities. Some exemplary services may include, but are not limited 
to, the following: (1) providing accurate, timely customer record updates, thus 
increasing the efficiency of marketing programs; (2) reducing customer service 
costs through minimization of call length by facilitating the identification of 

2 5 callers through their system 102 ID, thus providing instant access to the 

information necessary to resolve the customer complaint/ inquiry; (3) 
maintaining company employee and vendor information through the system 
102, either in a distributed manner as described above in reference to the contact 
manager 148 or through an independent system 102 licensed to the company; (4) 

3 0 listing company information in a business directory maintained by the system 
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102, which could be used in lieu of or to augment conventional directories such 
as the white and yellow pages; (5) simplifying customer electronic purchases by 
enabling customers to register with their site and perform transactions utilizing 
their system 102 ID and associated information, thus increasing fhe volume of 
5 completed transactions; (6) displaying privacy policies to customers and 

matching those policies with privacy preferences of the customer maintained by 
the system 102; (7) maintaining a digital certificate registry to search and track 
digital certificates of users so that the certificate authority can be automatically 
notified when a user changes relevant information; and (8) providing a data 

10 escrow service thereby escrowing credit card and other transaction information 
for on-line auction participants. 

It will be recognized by those skilled in the art that while the invention 
has been described above in terms of preferred embodiments, it is not limited 
thereto. Various features and aspects of the above-described invention may be 

15 used individually or jointly. Further, although the invention has been described 
in the context of its implementation in a particular environment and for 
particular applications, those skilled in the art will recognize that its usefulness 
is not limited thereto and that it can be utilized in any number of environments 
and applications and that its scope is limited only by the claims appended 

2 0 hereto. 
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CLAIMS 

What is claimed is: 

1 1. A data exchange engine for use with a database, comprising: 

2 a virtual record manager coupled to the database and configured to 

3 manage the storage of at least one data record in the database, the data record 

4 being managed at an individual data field level; and 

5 a data exchange engine coupled to the database-amd configured to 

6 support an exchange of the information in at least one data field between at 

7 least two parties, the exchange being based on a relationship between the 

8 parties, the relationship being represented in the database. 

1 2. The engine of claim 1 wherein the virtual record manager is configured to 

2 support a complex data record, the complex data record comprising a plurality 

3 of related data fields. 

1 3. The engine of claim 2 wherein the data exchange engine is configured to 

2 support the exchange of the information in the complex data record. 

1 4. The engine of claim 1 wherein the virtual record manager is configured to 

2 allow a unique type of data record to be created substantially instantaneous. 

1 5. The engine of claim 1 wherein the virtual record manager is configured to 

2 allow an instance of the data record to be allocated to the database substantially 

3 instantaneous. 

1 6. The engine of claim 1 wherein the virtual record manager is configured to 

2 assign each data field a unique identifier. 
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1 7. The engine of claim 1 wherein the virtual record manager is configured to 

2 associate each data field with a data record type and to manage each data field 

3 according to the data record type. 

1 8. The engine of claim 1 wherein the virtual record manager is configured to 

2 utilize a virtual object to manage the storage of the data record, the virtual 

3 object defining a data record structure being a logical grouping of individual 

4 data fields, the virtual object being described as a virtual object type whereby 

5 the virtual object type is configured to provide a description of the data record 

6 structure; 

7 wherein utilization of the virtual object allows a unique type of data record to 

8 be created substantially instantaneous. 

1 9. The engine of claim 8 wherein utilization of the virtual object allows an 

2 instance of the data record to be allocated to the database substantially 

3 instantaneous. 

1 10. The engine of claim 1 wherein the virtual record manager and the data 

2 exchange engine are configured to provide a means for a party to exchange 

3 specific data fields with all other parties with which the party has a 

4 relationship. 

1 11. The engine of claim 1 wherein the virtual record manager is configured to 

2 define a mapping between a third party data record format and a native data 

3 record format. 

1 12. The engine of claim 11 wherein the mapping utilizes extensible markup 

2 language. 
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1 13. The engine of claim 1, further comprising: 

2 an encryption engine coupled to the database and configured to manage 

3 the encryption of the data record prior to storage in the database. 

1 14. The engine of claim 13 wherein the encryption engine is configured to 

2 support a different encryption method for individual data fields of the data 

3 record . — ~ 

1 15. A personal information exchange system comprising: 

2 an interface layer configured to provide at least one interface application 

3 configured to facilitate communication with a user through a network; 

4 an application layer coupled to the interface layer and configured to 

5 provide a means to store the personal information of the user in a data 

6 repository; 

7 an exchange engine layer coupled to the application layer and 

8 configured to provide a means to manage storage of the personal information in 

9 a manner such that a type of personal information is instantiated substantially 
10 instantaneous; and 

H the data repository coupled to the exchange engine and configured to 

12 provide storage of information describing parties allowed access to at least a 

13 portion of the personal information. 

1 16. The system of claim 15 wherein the data repository is configured to provide 

2 storage of information describing the means to manage storage of the personal 

3 information. 

1 17. The system of claim 15 wherein the portion of personal information 

2 represents a data field in a data management system. 

1 18. The system of claim 15 wherein the network is a wireless network. 
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1 19. A method for providing dynamic contact information of a user of a 

2 dynamic information exchange system, comprising the steps of: 

3 invoking a record manager to obtain information identifying a party to 

4 which the user has permitted dynamic exchange of information; * 

5 invoking a data exchange means to obtain information identifying a data 

6 field of a data record to which the identified party has allowed exchange with 

7 the user; ~~ 

8 invoking the record manager to read from a memory a content of the 

9 identified data field; and 

10 providing the content to an interface for transmission to the user. 

1 20. A method for utilizing a virtual record manager to manage a virtual object 

2 defining a data record structure in an information storage system supporting 

3 real-time instantiation of data records, comprising the steps of: 

4 associating a type to the virtual object, the type being related to a 

5 description of data record content; 

6 creating a row in a first data table to store data related to the type; 

7 providing type metadata associated with the type to the virtual record 

8 manager, the type metadata describing the quantity of data fields constituent to 

9 the data record; 

10 creating a second data table, each row 7 in the second data table 

11 representing one of the data fields constituent to the data record; and 

12 providing field metadata associated with at least one data field to the 

13 virtual record manager, the field metadata describing the data record content; 

14 whereby the virtual record manager provides real-time instantiation of 

15 the data record. 
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1 21. A machine-readable medium having embodied thereon a program, the 

2 program being executable by a machine to perform method steps for 

3 exchanging information over a network, the method steps comprising: 

4 facilitating communication with a user through the network; 

5 managing storage of information of the user in a data repository in a 

6 manner such that a type of information is instantiated substantially 

7 instantaneous; and — 

8 providing storage of permissions information describing parties allowed 

9 access to at least a portion of the information. 

1 22. The machine-readable medium of claim 21, the method steps further 

2 comprising: 

3 associating an object type with the information; 

4 creating a row in a first data table to store object type metadata related to 

5 the object type, the object type metadata describing the quantity of data fields 

6 constituent to the information record; 

7 creating a second data table, each row in the second data table 

8 representing at least one of the data fields constituent to the information record; 

9 and 

10 providing field metadata associated with the at least one data field to a 

11 virtual record manager, the field metadata describing the information in the at 

12 least one data field; and 

13 providing real-time instantiation of the information record in the data 

14 repository based on the first and second data tables and the object type and 

15 field metadata. 
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1 23. A model for providing accurate real-time information services to a business 

2 entity, comprising the steps of: 

3 employing an information exchange system for managing storage of 

4 customer or employee information in a data repository and storage of 

5 permissions information describing parties allowed access to at least a portion 

6 of the information; 

7 offering the business entity at least one of the foHowing services based on 

8 the information and the permissions information managed by the information 

9 exchange system: 

10 providing an updated customer or employee database of the 

11 business entity; 

12 enabling a customer to provide information by providing a 

13 unique identification associated with the information exchange system; 

14 providing a business directory for listing automatically updated 

15 information about the business entity; 

16 providing notification upon a change in customer information; 

17 maintaining a registry of customer digital certificates; 

18 escrowing transaction data associated with a transaction wherein 

19 parties are remotely located from each other; and 

2 0 upon acceptance of one of the services by the business entity, charging 

2 1 the business entity a fee therefor. 

22 
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